Technical Field
This disclosure relates to methods and systems supporting computing and data processing systems. More particularly, the disclosure relates to processing messages using native data serialization/deserialization in a service-oriented pipeline architecture.
Related Art
In Services Oriented Architecture (SOA), there are typically many communicating reusable services that are deployed in several machines. In large-scale enterprises, like eBay, eTrade, or Google for example, there could be thousands of different services deployed in thousands of machines. It is most common and efficient for these services to communicate with each other. Further, external access is also typically provided for some of these services. In a typical model, business functions are implemented as re-usable services. Service consumers communicate with service producers/providers, typically using a web services protocol. In communicating with each other, various different types of communication protocols may be used for efficiency and optimization reasons. Communication between service providers and service consumers can be accomplished using some pre-defined protocol. In the web services case, this protocol can be the Simple Object Access Protocol (SOAP). SOAP is a protocol for exchanging Extensible Mark-up Language (XML)-based messages over computer networks, normally using Hypertext Transport Protocol (HTTP/HTTPS). SOAP often forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built. There are several different types of messaging patterns in SOAP; but, by far the most common is the Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another node (the server) and the server immediately sends a response message to the client.
Although SOAP can provide a communication or messaging protocol that can be used in some SOA implementations, sometimes there is a need for communicating using other protocols. For example, in some cases it may be beneficial or more efficient to use Representational State Transfer (REST) style HTTP messaging without any specific message protocol or some other proprietary protocol. Further, when not using SOAP as the protocol, the data format for exchanging messages doesn't necessarily have to be XML. When various different protocols are used, the SOA must either support all protocols and thereby become complex and inefficient, or the SOA is compatibility-restricted to operation only with one protocol. SOA's that support multiple protocols typically have different and independent message processing models. For example, an XML message received via SOAP in a conventional multi-protocol SOA is processed differently and independently from the processing performed on an XML message received via a protocol other than SOAP. Thus, the conventional multi-protocol SOA has some duplicated functionality and inefficiencies in the model and resource utilization.
Increasingly, these services are also used by a variety of clients, such as a java script, exchanging a message in JSON (Java Script Object Notation) data format or a browser exchanging a message in Name-Value (NV) format, and the like. Typical SOA frameworks implement a transformation layer where these other incoming data types or data formats are converted or normalized into a common format (e.g. SOAP/XML or otherwise) and then the common format is processed. Unfortunately, this transformation involves additional cost and time, and reduces the flexibility of the system when a needed data format is not supported. Thus, it would be advantageous to provide a system that did not perform a data format conversion or transformation into a common format.
U.S. Patent Application No. 2005/0223109 describes a system wherein services such as product services, real-time services, and common services are deployed in a services oriented architecture. These services may, for example, be deployed for use in a variety of enterprise data integration functions.
U.S. Patent Application No. 2007/0011126 describes a service-oriented architecture (SOA) and accompanying method. In one embodiment, the SOA includes one or more service requesters coupled to one or more service providers via a bus. The bus includes runtime-binding functionality to facilitate interaction between the one or more service requesters and the one or more service providers. A registry, which stores information pertaining to a service provided by the one or more service providers, communicates with one or more service providers and/or requesters and the bus. In a more specific embodiment, bus includes a Service-Integration Bus (SIB) that includes a Service-Factory (SF) module for facilitating implementing the runtime binding functionality and for selectively invoking the service. Functionality of the SOA is strategically organized into various tiers and layers, including a requester tier, a provider tier, a business-process services tier, an infrastructure-services tier, an SIB layer, a persistence layer, and so on.
U.S. Patent Application No. 2005/0267947 describes a system including a service bus, which can act as an intermediary between a client and a service. Messages to the service bus arrive on a transport and can be processed to determine a destination to route and/or publish the message to, a transformation to perform on the message, and/or security processing. The message is then sent out on a transport bound for a service or another service bus. A response to the message can follow an inverse path through the service bus.
Thus, a computer-implemented system and method for processing messages using native data serialization/deserialization in a service-oriented pipeline architecture, are needed.